An event is an action or occurrence that may be captured by a computing system. Examples of events include logging into a system, running a report, executing an Application Programming Interface (API), or other occurrences. For instance, a client application running on or otherwise accessible by a client device may include a user interface layer that presents a user interface. Through selection of a user interface element, a user of a client device may initiate some processing operation in a logical layer of the client application that reaches a hard limit (e.g., a number of processing cycles consumed per day or an amount of storage resources consumed) and page rendering is stopped. The reaching of this hard limit may trigger the creation of an event by the client application, which is recorded for possible future review.
In some cases, events generated by a client application and a corresponding client device are recorded by a multi-tenant system. A multi-tenant system is a system in which various elements of hardware and software may be shared by one or more tenants. For example, a given application server may process and provide access to events generated by client devices and associated with any number of tenants. In this multi-tenant system, processing of events is defined at compile time and is common to all events. Thus, a first event of a first type from a first client device and with a first set of associated permissions undergoes the same processing and is delivered to the same data stores (either for long term storage or for streaming) as a second event of a second type from a second client device and with a second set of associated permissions. This is often an inefficient use of both processing and storage resources as tenants typically utilize events differently (i.e., require different processing for delivery to different destinations). For instance, using the example above, a first tenant associated with or otherwise interested in the first event may want the first event routed only to a destination for long-term storage, while a second tenant associated with or otherwise interested in the second event may want the second event routed only to a destination for short-term storage (i.e., for stream processing). Since traditional systems require events to be treated in the same manner, both the first event and the second event will at least be processed and routed to both long-term and short-term storage destinations. By requiring both the first event and the second event to be processed and routed to both long-term and short-term storage destinations, which is at least partially contrary to the needs of the first and second tenants, processing and storage resources are inefficiently utilized in these systems. Further, since configuration of processing and routing is determined at compile time, any changes to the needs of either the first or second tenant requires recompilation of the system.